Description

This PR removes two pieces of dead code in the ADD action of the overlay reducer that can never be executed due to the control flow logic.

Changes

• Removed redundant if (overlay == null || overlay.isOpen) check

  • The outer condition already validates the overlay exists and is closed

• Simplified the ternary operator for overlayData

  • Changed from isExisted ? state.overlayData : { ...state.overlayData, [action.overlay.id]: action.overlay }
  • To always adding the overlay: { ...state.overlayData, [action.overlay.id]: action.overlay }
  • When isExisted is true, the first if block already handles the reopen case
  • The final return statement only executes when adding a completely new overlay

Motivation and Context

Both pieces of code represent unreachable paths:

1. Redundant null check: The outer if condition state.overlayData[action.overlay.id] != null && state.overlayData[action.overlay.id].isOpen === false already ensures the overlay exists and is closed, making the inner check impossible to trigger.

2. Unreachable ternary branch: When execution reaches the final return statement:

   • If overlayData[id] exists and is closed → handled by first if block
   • If overlayData[id] exists and is open → throws error
   • If overlayData[id] doesn't exist → new overlay, must be added to overlayData

   Therefore, isExisted can only be true if there's data inconsistency between overlayOrderList and overlayData, which shouldn't happen in normal operation.

Removing this dead code improves clarity and maintainability.

How Has This Been Tested?

• Verified existing unit tests in packages/src/context/reducer.test.ts pass
• Confirmed TypeScript compilation succeeds without type errors
• No behavioral changes - the logic flow remains identical

Screenshots (if appropriate):

This change improved test coverage to 100%.

Before	After

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have performed a self-review of my own code.
• My code is commented, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• Any dependent changes have been merged and published in downstream modules.

Further Comments

This refactoring removes two pieces of unreachable code without changing any behavior. The control flow analysis shows that both the redundant null check and the isExisted ternary branch can never execute in practice, making them safe to remove.